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(54) Automatic detection and patching of vulnerable files 



(57) Systems and methods are described that ena- 
blepatchingof security vulnerabilities in binary files. The 
detection and patching of vulnerable binary files is au- 
tomatic, reliable, regression free, and comprehensive 
across networks on an unlimited scale. These advan- 
tages can be realized in various ways including, for ex- 
ample, by leveraging current anti-virus infrastructure 



that is widely deployed across the Internet. Reliable dis- 
covery of vulnerable binary files (e.g., in operating sys- 
tems, application programs, etc) is achieved through 
the use of binary signatures that have been associated 
with discovered security vulnerabilities. A divergence of 
security patches away from conventional service packs 
provides for the possibility of production of regression- 
free fixes for security vulnerabilities in binary files. 
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Description 
TECHNICAL FIELD 

[0001] The present disclosure generally relates to 
patching files, and more particularly, to an automatic, 
comprehensive, reliable and regression-free way of pro- 
viding security patches for vulnerable binary program 
files in distributed, heterogeneous computing environ- 
ments. 

BACKGROUND 

[0002] Software development is an ongoing process 
whereby a software product initially released to the pub- 
lic can be continually updated through revisions from a 
software developer/vendor. Software revisions are typ- 
ically disbursed from a software vendor in what are 
called "service packs" that can be downloaded or or- 
dered from a vendor for installation on a user's compu- 
ter. Service packs typically contain program fixes (e.g., 
for an operating system, application program, etc.) that 
repair problems (i.e., "bugs") discovered in the program 
code after the initial release of the product or after the 
last service pack release. 

[0003] In addition to containing fixes for program 
bugs, service packs can also contain security patches 
developed specifically to repair vulnerabilities found in 
program files. Program vulnerabilities discovered after 
a software product is released can pose significant se- 
curity threat of attack from hackers and viruses on a 
world-wide basis. Therefore, once a vulnerability is dis- 
covered, the prompt and wide-spread distribution and 
installation of security patches to computers having vul- 
nerable software is of paramount importance. Theoret- 
ically, the use of service packs to achieve such prompt 
and wide-spread distribution of security patches could 
be effective. For example, when a software vendor dis- 
covers a vulnerability and then develops a security 
patch, the patch can be posted in the latest service pack 
on avendorWebsiteforusersto immediately download 
and install. This could thwart most hackers and viruses 
that are intent on exploiting the discovered vulnerability. 
However, system administrators and other software 
product users currently face several drawbacks and/or 
difficulties related to accessing and installing security 
patches. These difficulties typically result in a signifi- 
cantly lower distribution of such patches than is intended 
by the vendor who develops the patch . The result is that 
vulnerabilities on many computers world-wide are left 
unpatched, exposing such computers to significant risk. 
[0004] One difficulty with accessing and installing se- 
curity patches is that current methods for detecting 
whether a computer is running software with a known 
vulnerability require the active use and involvement of 
the computer. For example, currently available methods 
can determine whether particular versions of software 
products on a computer are in need of being updated 



(e.g., with a security patch). However, only those soft- 
ware products actively running on the computer are in- 
cluded in this determination. Secondary operating sys- 
tems and applications that are not actively running on a 

s computer are not considered, and therefore may have 
a security vulnerability that goes un-noticed and un- 
fixed. For those products actively running on a compu- 
ter, a user can review a list of available updates and se- 
lect updates for installation. Some updates may be crit- 

io ical updates designed to protect a computer from known 
security vulnerabilities. Various updates require a user 
to restart the computer before the installation is com- 
plete. In addition, a user must actively select the updates 
and install them. For these and other reasons, current 

'5 methods for accessing and installing security patches 
are less than effective. 

[0005] Another difficulty in accessing and installing 
security patches is that of knowing whether or not a se- 
curity patch is needed on a computer. It is sometimes 

20 difficult for users to know if their computers are running 
software that is vulnerable. Furthermore, current meth- 
ods for detecting whether a computer is running soft- 
ware with a known vulnerability may not be able to de- 
tect certain configurations of a software product known 

25 to be vulnerable. For example, shared versions of some 
software products can be distributed as part of other 
products. Thus, although a shared version of a product 
may contain the same vulnerability as the full version of 
the product, the shared version may not be recognized 

30 as a product that needs a security patch update. Thus, 
shared versions of software products that are known to 
have security vulnerabilities often go un-fixed. 
[0006] Other problems with accessing and installing 
security patches relate to the conventional "service 

35 pack" method by which such patches are delivered. 
Downloading and installing services packs is a time in- 
tensive and manual process that many system admin- 
istrators simply do not have time to perform. Therefore, 
even when administrators intend to install security 

40 patches, the time between the release of a security 
patch and its installation on a given system can be 
weeks, months, oryears. Thus, the riskof attackth rough 
a security vulnerability may not be alleviated in such sys- 
tems until long after the software vendor has issued a 

45 security patch. 

[0007] Furthermore, system administrators often 
choose not to download and install service packs con- 
taining security patches, even though they understand 
the relevant security risks. The reason forthis is that the 

so installation of a service pack itself brings the risk of sys- 
tem regressions that can introduce unwanted changes 
in system behavior. Administrators often devote signifi- 
cant time and effort toward debugging a system so that 
it functions as desired. As mentioned above, however, 

55 service packs represent an evolution of a previous ver- 
sion of a software product that includes the most recent 
updates to a product's code base (i.e., the scope of 
changes is not restricted to security patches only). In 
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addition to introducing new and intended behaviors into 
a system, recent code updates in a service pack may 
introduce unknown bugs into a system that can cause 
the system to behave unexpectedly, which, in turn, can 
create significant problems for a system administrator. 
Thus, systems frequently are not updated with important 
security patches intended to fix vulnerable program 
files, because administrators do not want to risk regres- 
sions. 

[0008] Accordingly a need exists for a way to imple- 
ment patching of security vulnerabilities in program files 
in an automatic, comprehensive, reliable and regres- 
sion-free manner. 

SUMMARY 

[0009] Automatic, comprehensive, reliable and re- 
gression-free security patching of binary program files 
is described herein. 

[0010] In accordance with one implementation, a bi- 
nary signature of a vulnerability and a security patch are 
received. A vulnerable binary file is identified on a com- 
puter based on the binary signature of a vulnerability. 
The vulnerable binary file on the computer is updated 
with the security patch. 

[0011] In accordance with another implementation, a 
binary signature is received that identifies a security vul- 
nerability in a binary file. A security patch configured to 
fix the security vulnerability is also received. The binary 
signature and the security patch are distributed to a plu- 
rality of servers. 

[0012] In accordance with another implementation, a 
binary signature is received from a server and used to 
search binary files. A request for a security patch is sent 
to the server if the binary signature is found in a binary 
file, The binary file is then updated with the security 
patch. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] The same reference numerals are used 
throughout the drawings to reference like components 
and features. 

Fig. 1 illustrates an exemplary network environment 
suitable for implementing automatic detection and 
patching of security vulnerabilities in binary files. 
Fig. 2 illustrates an exemplary embodiment of a dis- 
tribution server, a scan-patch server, and a client 
computer suitable for implementing automatic de- 
tection and patching of security vulnerabilities in bi- 
nary files. 

Fig. 3 illustrates another exemplary embodiment of 
a distribution server, a scan-patch server, and a cli- 
ent computer suitable for implementing automatic 
detection and patching of security vulnerabilities in 
binary files. 

Figs. 4 - 6 illustrate block diagrams of exemplary 



methods for implementing automatic detection and 
patching of security vulnerabilities in binary files. 
Fig. 7 illustrates an exemplary computing environ- 
ment suitable for implementing a distribution server, 
s a scan-patch server, and a client computer. 

DETAILED DESCRIPTION 

Overview 

[0014] Thefollowing discussion is directed to systems 
and methods that enable patching of security vulnera- 
bilities in binary files. The detection and patching of vul- 
nerable binary files is automatic, reliable, regression 

is free, and comprehensive across networks on an unlim- 
ited scale. These advantages can be realized in various 
ways including, for example, by leveraging current anti- 
virus infrastructure that is widely deployed across the 
Internet. A divergence of security patches away from 

20 conventional service packs provides for the possibility 
of production of regression-free fixes forsecurity vulner- 
abilities in binary files. 

[001 5] Reliable discovery of vulnerable binary files (e. 
g., in operating systems, application programs, etc.) is 

25 achieved through the use of binary signatures that have 
been associated with security vulnerabilities. Binary sig- 
natures associated with security vulnerabilities in binary 
files, along with security patches developed to fix such 
security vulnerabilities, are uploaded to a central distri- 

30 bution server. The distribution server is configured to 
distribute the binary signatures and security patches on 
a wide-scale basis across various networks such as the 
Internet. Use of a central distribution server to update 
network servers (e.g., across the Internet) provides 

35 comprehensive and automatic patch coverage on an 
unlimited scale. Network servers receiving such up- 
dates can scan client computers within subordinate net- 
works to locate vulnerable files according to binary sig- 
natures, and then update those computers found to 

40 have security vulnerable files using corresponding se- 
curity patches that will fix the vulnerable files. Network 
servers can also communicate with client computers to 
transfer binary signatures and security patches to the 
computers so that the scanning and updating can be 

45 performed by the computers themselves. Multiple nest- 
ed levels of subordinate networks may also exist. 

Exemplary Environment 

so [0016] Fig. 1 illustrates an exemplary network envi- 
ronment 1 00 suitablefor implementing automatic detec- 
tion and patching of security vulnerabilities in binary 
files. In the exemplary network environment 1 00, a cen- 
tral distribution server 102 is coupled to multiple scan/ 

55 patch servers 104 via a network 106(a). A scan/patch 
server 104 is typically coupled through a network 106 
(b) to a plurality of client computers 1 08(1 ) - 1 08(n). Net- 
work 1 06 is intended to represent any of a variety of con- 
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ventional network topologies and types (including opti- 
cal, wired and/or wireless networks), employing any of 
a variety of conventional network protocols (including 
public and/or proprietary protocols). Network 106 may 
include, for example, the Internet as well as possibly at 
least portions of one or more local area networks (LANs) 
and/or wide area networks (WANs). Networks 106(a) 
and 106(b) maybe the same network such as the Inter- 
net, or they may be networks isolated from one another 
such as the Internet and a corporate LAN. 
[0017] Distribution server 1 02 and scan/patch servers 
1 04 are typically implemented as standard Web servers, 
and can each be any of a variety of conventional com- 
puting devices, including desktop PCs, notebook or 
portable computers, workstations, mainframe comput- 
ers, Internet appliances, combinations thereof, and so 
on. One or more of the servers 1 02 and 1 04 can be the 
same types of devices, or alternatively different types of 
devices. An exemplary computing environment for im- 
plementing a distribution server 102 and a scan/patch 
server 1 04 is described in more detail herein below with 
reference to Fig. 7. 

[0018] Client computers 108 function in a typical cli- 
ent/server relationship with a server 104 wherein multi- 
ple clients 1 08 make requests to a server 1 04 that serv- 
ices the requests. Client computers 108 can be any of 
a variety of conventional computing devices, including 
desktop PCs, notebook or portable computers, worksta- 
tions, mainframe computers, gaming consoles, hand- 
held PCs, cellular telephones or other wireless commu- 
nications devices, personal digital assistants (PDAs), 
combinations thereof, and so on. One or more of the 
client computers 108 can be the same types of devices, 
or alternatively different types of devices. An exemplary 
computing environment for implementing a client com- 
puter 1 08 is described in more detail herein below with 
reference to Fig. 7. 

[0019] In general, automatic and comprehensive de- 
tection and patching of vulnerable binary files on client 
computers 108 is achieved through updates made 
through distribution server 102 that include binary sig- 
natures for identifying vulnerable binary files and secu- 
rity patches configured to fix vulnerable files. As dis- 
cussed in greater detail below with respect to the follow- 
ing exemplary embodiments, the binary signatures and 
security patches are distributed to scan/patch servers 
104 which in turn, either actively scan for and update 
vulnerable binary files on client computers 1 08, or push 
the binary signatures and security patches down to the 
client computers 108 so the client computers 108 can 
perform the scanning for and patching of vulnerable bi- 
nary files. 

Exemplary Embodiments 

[0020] Fig. 2 illustrates an exemplary embodiment of 
a distribution server 102, a scan-patch server 104 and 
a client computer 108 suitable for implementing auto- 



matic detection and patching of security vulnerabilities 
in binary files. Distribution server 102 includes a distri- 
bution module 200 and a database 202 for receiving and 
holding binary signatures and security patches. Data- 

s base 202 can be updated with binary signatures and se- 
curity patches in a variety of ways including, for exam- 
ple, through a portable storage medium (not shown, but 
see Fig. 7) or through a computer device (not shown) 
coupled to the server 1 02 and configured to upload bi- 

10 nary signatures and security patches to database 202. 
[0021] A typical scenario in which a database 202 
might be updated begins with an investigation of a soft- 
ware product (e.g.. a operating system, application pro- 
gram, etc.) initiated by the developer of the software 

is product. For example, a developer may hire a security 
consultancy firm to attempt to find security vulnerabili- 
ties in a newly released software product. If a security 
vulnerability is discovered in a software product through 
hacking or by some other means, an exact bit pattern of 

20 the vulnerable function within the product can be iden- 
tified. The bit pattern represents a binary signature of 
the vulnerable section in the binary file, which is a com- 
ponent of a software product. 

[0022] Once a security vulnerability is discovered and 
25 analyzed, a fix can be developed that will eliminate the 
vulnerability. Such fixes are called security patches and 
they represent revised code modules compiled into bi- 
nary executables. Security patches can be installed on 
computers that are identified through the binary signa- 
30 ture as running software that has the security vulnera- 
bility. Installation of the security patch will fix the security 
vulnerability. The distribution server 102 enables soft- 
ware product vendors and others to upload binary sig- 
natures of vulnerable binary files along with the security 
35 patches designed to fix the vulnerable binary files, into 
the database 202 for distribution. 
[0023] Distribution module 200 is configured to dis- 
tribute binary signatures and security patches from da- 
tabase 202 to various scan-patch servers 1 04 via a net- 
40 work 106. Distribution module 200 typically functions 
automatically to distribute binary signatures and securi- 
ty patches from database 202 whenever the database 
202 is updated with additional signatures and patches. 
Automatic distribution may be achieved in a variety of 
45 ways including, for example, through communication 
from distribution module 200 to scan-patch servers 1 04 
indicating that updated binary signatures and security 
patches are available and waiting for requests to send 
the binary signatures and security patches, or by auto- 
50 matically forwarding updated binary signatures and se- 
curity patches to scan-patch servers 104 configured to 
accept the updates. 

[0024] In the embodiment of Fig. 2, a scan-patch serv- 
er 104 includes a scan-patch module 204 and a data- 
55 base 206 for receiving and holding binary signatures 
and security patches. Database 206 is typically updated 
automatically with new binary signatures and security 
patches through communications between the scan- 
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patch module 204 and the distribution module 200 on 
distribution server 1 02. In addition to updating database 
206 with binary signatures and security patches, scan- 
patch module 204 is configured to access client compu- 
ter 1 08 and scan binary files 208 for binary signatures. 
Scanning binary files 208 can include searching for a 
binary signature in binary files present on any form of 
media present on or accessible by client computer 1 08. 
Binary files 208 typically include compiled, computer/ 
processor-readable code such as an operating system 
or an application program file. However, it is noted that 
binary files 208 can be any form of binary information 
including computer/processor-readable instructions, 
data structures, program modules, and other data for 
client computer 108. 

[0025] As noted below in the discussion referring to 
the exemplary computer environment of Fig. 7, such 
media on a client computer 1 08 can include any availa- 
ble media that is accessible by client computer 108, 
such as volatile and non-volatile media as well as re- 
movable and non-removable media. Such computer/ 
processor-readable media can include volatile memory, 
such as random access memory (RAM) and/or non-vol- 
atile memory, such as read only memory (ROM). Com- 
puter/processor-readable media can also include other 
removable/non-removable, volatile/non-volatile compu- 
ter storage media, such as, for example, a hard disk 
drive for reading from and writing to a non-removable, 
non-volatile magnetic media, a magnetic disk drive for 
reading from and writing to a removable, non-volatile 
magnetic disk (e.g., a "floppy disk"), an optical disk drive 
for reading from and/or writing to a removable, non-vol- 
atile optical disk such as a CD-ROM, DVD-ROM, or oth- 
er optical media, other magnetic storage devices, flash 
memory cards, electrically erasable programmable 
read-only memory (EEPROM), network-attached stor- 
age, and the like. All such computer/processor-readable 
media providing both volatile and non-volatile storage 
of any form of binary files 208, including computer/proc- 
essor-readable instructions, data structures, program 
modules, and other data for client computer 1 08, is ac- 
cessible for scanning by scan-patch server 104 via 
scan-patch module 204. 

[0026] Scan-patch module 204 thus searches binary 
files 208 on client computer 1 08 to determine if a binary 
signature identifying a security vulnerability is present 
in any binary information located on client computer 
1 08. If the bit pattern of the binary signature is found in 
a binary file 208, scan-patch module 204 operates to fix 
the security vulnerability in the binary file 208 by install- 
ing a corresponding security patch on client computer 
108. Installation of a security patch on client computer 
1 08 overwrites or otherwise eliminates the binary file or 
a portion of the binary file containing the security vulner- 
ability. 

[0027] Fig. 3 illustrates another exemplary embodi- 
ment of a distribution server 102, a scan-patch server 
1 04 and a client computer 1 08 suitable for implementing 



patching of security vulnerabilities in binary files. In gen- 
eral, in the Fig. 3 embodiment, binary signatures and 
security patches are pushed down, or redistributed, 
from the server 1 04 to the client computer 1 08, and the 

s scanning for security vulnerable files and the patching 
of security vulnerable files is performed by the client 
computer 1 08 instead of the scan patch server 1 04. 
[0028] In the Fig. 3 embodiment, distribution server 
102 is configured in the same manner as discussed 

10 above with respect to the embodiment of Fig. 2. Thus, 
database 202 can be updated to include newly discov- 
ered binary signatures that identify security vulnerabili- 
ties in binary files. Database 202 can also be updated 
with corresponding security patches that have been de- 

'5 veloped to fix such security vulnerabilities. 

[0029] The scan-patch server 102 of Fig. 3 is config- 
ured in somewhat the same manner as that discussed 
above with respect to Fig. 2. Thus, scan-patch server 
1 02 of Fig. 3 includes a database 206 for receiving and 

20 holding binary signatures and security patches. Data- 
base 206 is typically updated automatically with new bi- 
nary signatures and security patches through commu- 
nications between the scan-patch server 104 and the 
distribution server 102. However, the communication 

25 between the scan-patch server 1 04 and the distribution 
server 102 is conducted through a redistribution module 
300 instead of a scan-patch module 204 as discussed 
with respect to the Fig. 2 embodiment. 
[0030] The redistribution module 300, in addition to 

30 updating database 206 with binary signatures and se- 
curity patches, is configured lo communicate with scan- 
patch module 302 on client computer 108 and transfer 
a binary signature to the client computer 108. Scan- 
patch module 302 is configured to receive the binary sig- 

35 nature and to scan binary files 208 to determine if the 
binary signature is present in any binary information lo- 
cated on client computer 108. Thus, the scan-patch 
module 302 of Fig. 3 functions in a manner similar to the 
scan-patch module 204 discussed above with reference 

40 to Fig. 2. 

[0031 ] If the bit pattern of the binary signature is found 
in a binary file 208 on client computer 1 08, scan-patch 
module 302 sends a request to the redistribution module 
300 on server 102. The request is to have the redistri- 

45 bution module 300 send the security patch correspond- 
ing with the binary signature down to the client computer 
108. The redistribution module 300 responds to the re- 
quest by sending the appropriate security patch to client 
computer 1 08. The scan-patch module 302 receives the 

so security patch and operates to fix the security vulnera- 
bility in the binary file 208 by installing the security patch 
on client computer 108. As in the Fig. 2 embodiment, 
installation of a security patch on client computer 108 
overwrites or otherwise eliminates the binary file or a 

55 portion of the binary file containing the discovered se- 
curity vulnerability. 



5 



EP 1 505 499 A1 



10 



Exemplary Methods 

[0032] Example methods for implementing automatic 
detection and patching of security vulnerabilities in bi- 
nary files will now be described with primary reference 
to the flow diagrams of Figs. 4 - 6. The methods apply 
generally to the exemplary embodiments discussed 
above with respect to Figs. 1 - 3. The elements of the 
described methods may be performed by any appropri- 
ate means including, for example, by hardware logic 
blocks on an ASIC or by the execution of processor- 
readable instructions defined on a processor-readable 
medium. 

[0033] A "processor-readable medium," as used 
herein, can be any means that can contain, store, com- 
municate, propagate, or transport instructions for use by 
or execution by a processor. A processor-readable me- 
dium can be, without limitation, an electronic, magnetic, 
optical, electromagnetic, infrared, or semiconductor 
system, apparatus, device, or propagation medium. 
More specific examples of a processor-readable medi- 
um include, among others, an electrical connection 
(electronic) having one or more wires, a portable com- 
puter diskette (magnetic), a random access memory 
(RAM) (magnetic), a read-only memory (ROM) (mag- 
netic), an erasable programmable-read-only memory 
(EPROM or Flash memory), an optical fiber (optical), a 
rewritable compact disc (CD-RW) (optical), and a port- 
able compact disc read-only memory (CDROM) (opti- 
cal). 

[0034] Fig. 4 shows an exemplary method 400 for im- 
plementing automatic detection and patching of security 
vulnerabilities in binary files, The binary files are typical- 
ly located or stored on a client computer being served 
by a server computer, but they may also be located on 
the server computer itself, or any other computing de- 
vice accessible by the server computer. At block 402 of 
method 400, a binary signature is received. The binary 
signature is a bit pattern that has been associated with 
a security vulnerability in a particular binary file, such as 
an executable application program or operating system 
running on a client computer. The binary signature is re- 
ceived from a central distribution server 102 by a sub- 
ordinate server 104. 

[0035] At block 404, a security patch is received. The 
security patch is typically compiled executable code that 
has been developed as a fix to the security vulnerability 
of the particular binary file. The security patch is also 
received from the central distribution server 1 02 by the 
subordinate server 104. At block 406, a vulnerable bi- 
nary file is identified based on the binary signature. The 
identification of the vulnerable binary file is typically 
achieved by scanning binary information stored on var- 
ious media of a computer, such as client computer 1 08, 
and then comparing the pattern(s) in the binary signa- 
ture with the binary information found on the media. The 
identification can happen in various ways including, for 
example, by the server 1 04 scanning and comparing all 



the binary information present on the client computer. 
The identification of a vulnerable binary file can also be 
achieved by having the server 1 04 push the binary sig- 
nature down to the client computer so that the client 

s computer can perform the scan and comparison. 
[0036] At block 408 of method 400, the security patch 
is used to update the vulnerable binary file. The update 
can be achieved in various ways including , for example, 
by the server 1 04 installing the security patch on the cli- 

10 ent computer 108. If the client computer 108 has per- 
formed the scan and identified the vulnerable binary file, 
the client computer 1 08 may request that the server 1 04 
send the security patch to the computer 108, in which 
case the computer 108 can install the security patch to 

'5 fix the vulnerable binary file. 

[0037] Fig. 5 shows another exemplary method 500 
for implementing automatic detection and patching of 
security vulnerabilities in binary files. The method 500 
generally illustrates the distribution of binary signatures 

20 for security vulnerabilities and the security patches de- 
veloped for fixing those security vulnerabilities. At block 
502 of method 500, a binary signature is received that 
identifies a security vulnerability of a binary file. The bi- 
nary signature is typically uploaded to a distribution 

25 server 1 02 as a newly discovered bit pattern that iden- 
tifies a vulnerability in a binary file of a software product 
that may be widely distributed across many computers 
on a network such as the Internet. The upload is typically 
achieved from a computer coupled to the distribution 

30 server 1 02 or from a portable storage medium inserted 
into the distribution server 1 02. At block 504, a security 
patch configured to fix the security vulnerability is re- 
ceived by the distribution server 1 02 in a similar manner 
as the binary signature. 

35 [0038] At block 506, the binary signature and the se- 
curity patch are distributed to a plurality of subordinate 
servers 104 from distribution server 102. This distribu- 
tion occurs automatically and can be achieved in various 
ways. For example, upon receiving an uploaded binary 

40 signature and security patch, the distribution server 1 02 
can automatically send the binary signature and security 
patch out over the network to all subordinate servers 
104 configured to receive updated binary signatures 
and security patches. The distribution server 1 02 might 

45 also send a notice to servers 104 indicating that a se- 
curity vulnerability has been discovered and that a se- 
curity patch is available to fix the vulnerability. Subordi- 
nate servers 104 can then request that the distribution 
server 1 02 send the binary signature that identifies the 

so security vulnerability and the security patch. Upon re- 
ceiving a request, the distribution server 102 can for- 
ward the binary signature and the security patch to re- 
questing servers 102. 

[0039] Fig. 6 shows another exemplary method 600 
55 for implementing automatic detection and patching of 
security vulnerabilities in binary files. At block 602 of 
method 600, a client computer 108 receives a binary sig- 
nature from a server 1 04. The binary signature is asso- 
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ciated with a security vulnerability in a binary file that 
may be present on the client computer 108. At block 
604, the client computer 108 scans all the binary infor- 
mation presently available to it and compares the pat- 
terns) in the binary signature with the binary informa- 
tion. The binary information scanned by the client com- 
puter 1 08 is typically in the form of computer/processor- 
readable and/or executable instructions, data struc- 
tures, program modules, and other data useful for client 
computer 1 08, and can reside on both volatile and non- 
volatile storage media of various types. 
[0040] At block 606, if the client computer 1 08 finds a 
binary file that contains the binary signature, it sends a 
request to the server 104 to have the security patch 
transferred. At block 608, the client computer 108 re- 
ceives the security patch, and at block 610, the client 
computer 108 installs the security patch in order to fix 
the security vulnerability in the binary file containing bi- 
nary information matching the pattern(s) in the binary 
signature. 

[0041] While one or more methods have been dis- 
closed by means of flow diagrams and text associated 
with the blocks of the flow diagrams, it is to be under- 
stood that the blocks do not necessarily have to be per- 
formed in the order in which they were presented, and 
that an alternative order(s) may result in similar advan- 
tages. Furthermore, the methods are not exclusive and 
can be performed alone or in combination with one an- 
other. 

Exemplary Computer 

[0042] Fig. 7 illustrates an exemplary computing en- 
vironment suitable for implementing a distribution server 
102, a scan-patch server 104, and a client computer 
108, as discussed above with reference to Figs. 1 - 3. 
Although one specific configuration is shown in Fig. 7, 
distribution server 102, scan-patch server 104, and cli- 
ent computer 1 08 may be implemented in other comput- 
ing configurations. 

[0043] The computing environment 700 includes a 
general-purpose computing system in the form of a 
computer 702. The components of computer 702 can 
include, but are not limited to, one or more processors 
or processing units 704, a system memory 706, and a 
system bus 708 that couples various system compo- 
nents including the processor 704 to the system mem- 
ory 706. 

[0044] The system bus 708 represents one or more 
of any of several types of bus structures, including a 
memory bus or memory controller, a peripheral bus, an 
accelerated graphics port, and a processor or local bus 
using any of a variety of bus architectures. An example 
of a system bus 708 would be a Peripheral Component 
Interconnects (PCI) bus, also known as a Mezzanine 
bus. 

[0045] Computer 702 typically includes a variety of 
computer-readable media. Such media can be any 



available media that is accessible by computer 702 and 
includes both volatile and non-volatile media, remova- 
ble and non-removable media. The system memory 706 
includes computer readable media in the form of volatile 

s memory, such as random access memory (RAM) 710, 
and/or non-volatile memory, such as read only memory 
(ROM) 712. A basic input/output system (BIOS) 714, 
containing the basic routines that help to transfer infor- 
mation between elements within computer 702, such as 

10 during start-up, is stored in ROM 712. RAM 710 typically 
contains data and/or program modules that are imme- 
diately accessible to and/or presently operated on by the 
processing unit 704. 

[0046] Computer 702 can also include other remova- 

15 ble/non-removable, volatile/non-volatile computer stor- 
age media. By way of example, Fig. 7 illustrates a hard 
disk drive 71 6 for reading from and writing to a non-re- 
movable, non-volatile magnetic media (not shown), a 
magnetic disk drive 718 for reading from and writing to 

20 a removable, non-volatile magnetic disk 720 (e.g., a 
"floppy disk"), and an optical disk drive 722 for reading 
from and/or writing to a removable, non-volatile optical 
disk 724 such as a CD-ROM, DVD-ROM, or other opti- 
cal media. The hard disk drive 71 6, magnetic disk drive 

25 718, and optical disk drive 722 are each connected to 
the system bus 708 by one or more data media interfac- 
es 726. Alternatively, the hard disk drive 716, magnetic 
disk drive 718, and optical disk drive 722 can be con- 
nected to the system bus 708 by a SCSI interface (not 

30 shown). 

[0047] The disk drives and their associated computer- 
readable media provide non-volatile storage of compu- 
ter readable instructions, data structures, program mod- 
ules, and other data for computer 702. Although the ex- 

35 ample illustrates a hard disk 71 6, a removable magnetic 
disk 720, and a removable optical disk 724, it is to be 
appreciated that other types of computer readable me- 
dia which can store data that is accessible by a compu- 
ter, such as magnetic cassettes or other magnetic stor- 

40 age devices, flash memory cards, CD-ROM, digital ver- 
satile disks (DVD) or other optical storage, random ac- 
cess memories (RAM), read only memories (ROM), 
electrically erasable programmable read-only memory 
(EEPROM), and the like, can also be utilized to imple- 

45 ment the exemplary computing system and environ- 
ment 

[0048] Any number of program modules can be stored 
on the hard disk 716, magnetic disk 720, optical disk 
724, ROM 712, and/or RAM 710, including by way of 

so example, an operating system 726, one or more appli- 
cation programs 728, other program modules 730, and 
program data 732. Each of such operating system 726, 
one or more application programs 728, other program 
modules 730, and program data 732 (or some combi- 

55 nation thereof) may include an embodiment of a caching 
scheme for user network access information. 
[0049] Computer 702 can include a variety of compu- 
ter/processor readable media identified as communica- 
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tion media. Communication media typically embodies 
computer readable instructions, data structures, pro- 
gram modules, or other data in a modulated data signal 
such as a carrier wave or other transport mechanism 
and includes any information delivery media. The term 
"modulated data signal" means a signal that has one or 
more of its characteristics set orchanged in such a man- 
ner as to encode information in the signal. By way of 
example, and not limitation, communication media in- 
cludes wired media such as a wired network or direct- 
wired connection, and wireless media such as acoustic, 
RF, infrared, and otherwireless media. Combinations of 
any of the above are also included within the scope of 
computer readable media. 

[0050] A user can enter commands and information 
into computer system 702 via input devices such as a 
keyboard 734 and a pointing device 736 (e.g., a 
"mouse"). Other input devices 738 (not shown specifi- 
cally) may include a microphone, joystick, game pad, 
satellite dish, serial port, scanner, and/orthe like. These 
and other input devices are connected to the processing 
unit 704 via input/output interfaces 740 that are coupled 
to the system bus 708, but may be connected by other 
interface and bus structures, such as a parallel port, 
game port, or a universal serial bus (USB). 
[0051] A monitor 742 or other type of display device 
can also be connected to the system bus 708 via an in- 
terface, such as a video adapter 744. In addition to the 
monitor 742, other output peripheral devices can include 
components such as speakers (nol shown) and a printer 
746 which can be connected to computer 702 via the 
input/output interfaces 740. 

[0052] Computer 702 can operate in a networked en- 
vironment using logical connections to one or more re- 
mote computers, such as a remote computing device 
748. By way of example, the remote computing device 
748 can be a personal computer, portable computer, a 
server, a router, a network computer, a peer device or 
other common network node, and the like. The remote 
computing device 748 is illustrated as a portable com- 
puter that can include many or all of the elements and 
features described herein relative to computer system 
702. 

[0053] Logical connections between computer 702 
and the remote computer 748 are depicted as a local 
area network (LAN) 750 and a general wide area net- 
work (WAN) 752. Such networking environments are 
commonplace in offices, enterprise-wide computer net- 
works, intranets, and the Internet. When implemented 
in a LAN networking environment, the computer 702 is 
connected to a local network 750 via a network interface 
or adapter 754. When implemented in a WAN network- 
ing environment, the computer 702 typically includes a 
modem 756 or other means for establishing communi- 
cations over the wide network 752. The modem 756, 
which can be internal or external to computer 702, can 
be connected to the system bus 708 via the input/output 
interfaces 740 or other appropriate mechanisms: It is to 



be appreciated that the illustrated network connections 
are exemplary and that other means of establishing 
communication link(s) between the computers 702 and 
748 can be employed. 
s [0054] In a networked environment, such as that illus- 
trated with computing environment 700, program mod- 
ules depicted relative to the computer 702, or portions 
thereof, may be stored in a remote memory storage de- 
vice. By way of example, remote application programs 
10 758 reside on a memory device of remote computer 748. 
For purposes of illustration, application programs and 
other executable program components, such as the op- 
erating system, are illustrated herein as discrete blocks, 
although it is recognized that such programs and corn- 
's ponents reside at various times in different storage com- 
ponents of the computer system 702, and are executed 
by the data processor(s) of the computer. 

Conclusion 

20 

[0055] Although the invention has been described in 
language specific to structural features and/or method- 
ological acts, it is to be understood that the invention 
defined in the appended claims is not necessarily limited 
25 to the specific features or acts described. Rather, the 
specific features and acts are disclosed as exemplary 
forms of implementing the claimed invention, 



30 Claims 

1. A processor-readable medium comprising proces- 
sor-executable instructions configured for: 

35 receiving a binary signature; 

receiving a security patch; 
identifying a vulnerable binary file on a compu- 
ter based on the binary signature; and 
updating the vulnerable binary file on the com- 

40 puter with the security patch. 

2. A processor-readable medium as recited in claim 1 , 
wherein the identifying a vulnerable binary file on a 
computer includes comparing a bit pattern of the bi- 

45 nary signature against binary files located on the 
computer, the bit pattern associated with a security 
vulnerability. 

3. A processor-readable medium as recited in claim 1 , 
so wherein the updating the vulnerable binary file on 

the computer includes installing the security patch 
on the computer. 

4. A processor-readable medium as recited in claim 1 , 
55 wherein the identifying a vulnerable binary file on a 

computer includes sending the binary signature to 
the computer. 
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5. A processor-readable medium as recited in claim 4, 
wherein the updating the vulnerable binary file on 
the computer includes: 

receiving a request from the computer to send 

the security patch; and 

sending the security patch to the computer. 

6. A processor-readable medium as recited in claim 1 , 
wherein the computer is a client computer and the 
receiving includes receiving the binary signature 
and the security patch from a distribution server 
configured to distribute to the client computer, bina- 
ry signatures that identify vulnerable files and secu- 
rity patches configured to fix the vulnerable files. 

7. A server comprising the processor-readable medi- 
um as recited in claim 1 . 

8. A processor-readable medium comprising proces- 
sor-executable instructions configured for: 

receiving a binary signature that identifies a se- 
curity vulnerability in a binary file; 
receiving a security patch configured to fix the 
security vulnerability in the binary file; and 
distributing the binary signature and the secu- 
rity patch to a plurality of servers. 

9. A processor-readable medium as recited in claim 8, 
wherein the distributing includes: 

sending a notice to each of the plurality of serv- 
ers regarding the security vulnerability and the 
available patch; 

receiving a requestto send the binary signature 
and the security patch; and 
sending the binary signature and the security 
patch in response to the request. 

10. A distribution server comprising the processor- 
readable medium as recited in claim 8. 

11. A processor-readable medium comprising proces- 
sor-executable instructions configured for: 

receiving a binary signature from a server; 
searching for the binary signature in binary 
files; 

sending a request to the server for a security 
patch if a binary file is found that includes the 
binary signature; 

receiving the security patch from the server; 
and 

updating the binary file with the security patch. 

12. A client computer comprising the processor-reada- 
ble medium as recited in claim 11 . 



13. A method comprising: 

receiving a binary signature; 
searching for a vulnerable file based on the bi- 
s nary signature; 

if a vulnerable file is found, requesting a secu- 
rity patch; and 

fixing the vulnerable file with the security patch. 

10 14. A method as recited in claim 13, wherein the re- 
questing includes sending a request to a server for 
the security patch, the method further comprising 
receiving the security patch from the server in re- 
sponse to the request. 

15. A method as recited in claim 14, wherein the receiv- 
ing includes receiving the binary signature from the 
server. 

20 16. A method as recited in claim 13, wherein the fixing 
includes installing the security patch on a computer. 

17. A method as recited in claim 13, wherein the 
searching includes comparing the binary signature 

25 to binary information on a storage medium of a com- 
puter. 

18. A method as recited in claim 1 7, wherein the binary 
information is selected from the group comprising: 

30 

an operating system; 

an application program file; and 

a data file. 

35 19. A method as recited in claim 17, wherein the stor- 
age medium is selected from the group comprising: 

a hard disk; 
a magnetic floppy disk; 
40 an optical disk; 

a flash memory card; 

an electrically erasable programmable read- 
only memory; and 
network-attached storage. 

45 

20. A method comprising: 

receiving a binary signature and a security 
patch from a distribution server; 
so searching on aclientcomputerforavulnerable 

file associated with the binary signature; and 
if a vulnerable file is found, fixing the vulnerable 
file with the security patch. 

55 21. A method as recited in claim 20, wherein the 
searching includes transferring the binary signature 
to the client computer, the client computer config- 
ured to search for a vulnerable file associated with 
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the binary signature. 

22. A method as recited in claim 21 , wherein the fixing 
includes: 

receiving a request from the client computer to 
transfer the security patch, the client computer 
having located a vulnerable file; and 
transferring the security patch to the client com- 
puter in response to the request. 

23. A computer comprising: 

means for receiving a binary signature; 
means for searching for a vulnerable file based 
on the binary signature; 
means for requesting a security patoh if a vul- 
nerable file is found; and 
means for fixing the vulnerable file with the se- 
curity patch. 

24. A server comprising: 

means for receiving a binary signature and a 
security patch from a distribution server; 
means for scanning a client computer for a vul- 
nerable file associated with the binary signa- 
ture; and 

means for fixing the vulnerable Tile with Ihe se- 
curity patch if a vulnerable file is found. 

25. A computer comprising: 

binary information; 

a scan module configured to receive a binary 
signature and scan the binary information for 
the binary signature; and 
a patch module configured to request a security 
patch and install the security patch if the binary 
signature is found in the binary information. 

26. A computer as recited in claim 25, further compris- 
ing a storage medium configured to retain the binary 
information. 



the binary signature from a server and to scan 
the binary files in search of the binary signature. 

29. A computer as recited in claim 28, further compris- 
ing: 

a binary file that includes the binary signature; 
and 

a security patch; 

wherein the security patch module is further 
configured to request the security patch from the 
server upon locating the binary signature within the 
binary file, and to apply the security patch to the bi- 
nary file. 

30. A distribution server comprising: 

a database; and 

a distribution module configured to receive a bi- 
nary signature and a security patch, store the 
binary signature and the security patch in the 
database, and distribute the binary signature 
and the security patch to a plurality of servers. 

31. A distribution server as recited in claim 30, wherein 
the distribution module is further configured to re- 
ceive a request from a server for the binary signa- 
ture and the security patch and to distribute the bi- 
nary signature and the security patch to the server 
in response to the request. 

32. A server comprising: 

a binary signature associated with a security 

vulnerability in a binary file; 

a security patch configured to fix the security 

vulnerability in the binary file; and 

a scan module configured to scan binary files 

on a client computer for the binary signature 

and to update the binary file with the security 

patch if the binary signature is found. 

33. A server as recited in claim 32, further comprising: 



27. A computer as recited in claim 25, wherein the bi- 
nary information is selected from the group com- 



an operating system; 

an application program file; and 

a data file. 



a database; 

the scan module further configured to receive 
the binary signature and the security patch from 
a distribution server and to store the binary sig- 
nature and the security patch ir 



28. A computer comprising: 
binary files; 

a binary signature; and 

a security patch module configured to receive 
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